Codecov Report

Attention: Patch coverage is 85.71429% with 6 lines in your changes missing coverage. Please review.

Project coverage is 89.48%. Comparing base (7865be8) to head (d14819d).

@@            Coverage Diff             @@
##           master    #1439      +/-   ##
==========================================
- Coverage   89.49%   89.48%   -0.02%     
==========================================
  Files          63       65       +2     
  Lines       10618    10642      +24     
==========================================
+ Hits         9503     9523      +20     
- Misses       1115     1119       +4     

In the design doc discussion, @silent was the most controversial annotation; it was agreed that @gpu should be the first one.
I think it would be enough for the initial implementation of @gpu to check that the mem_pattern is SoA after optimization and emit a warning if not. Annotation-aware optimization passes can be added later.

I'd prefer formatting the annotation on its own line (like a Python function decorator)

@gpu
matrix[N,M] x;

This is more or less required for longer parametrized annotations, such as the hypothetical @extern("file.cpp" :: namespace).

Checking that the annotation belongs to a list of known annotations may be enough to catch typos, but you should also warn about inapplicable annotations (e.g. @silent on a function or non-toplevel variable, @extern on a function with a body)

@gpu would make the most sense to be implemented 1) by someone other than myself who understands them more, and 2) as part of something like #1353. In particular, at the moment in the compiler there is a lot of legacy opencl stuff that does not interact with the SoA memory pattern things.

@silent was my motivation to getting around to actually implement this, since it seems to be a feature users ask for often (1, 2, 3, 4, stan-dev/cmdstan#553), and with the jacobian += changes encouraging more user-defined transforms I imagine it would be even more so. But it does have concerns with other features, so I would be willing to pull it into another PR for separate discussion

Formatting is currently set up with a hv box, so it will fit on one line if it can, but as soon as it can't, every annotation will appear on its own line. We could easily use a vbox instead if that's preferred -- I have a slight preference towards saving lines if they're short annotations

More advanced warnings are definitely something I want to look at before this becomes a non-draft; part of the issue is a lot of annotation logic will inherently live in the lower parts of the compiler, which currently never emit warnings, so wiring it up in a reasonable way requires some thinking